1. Field of the Invention
This invention relates to an electronic network and its operation, more specifically to a zone merge operations within such a network.
2. Description of the Related Art
The Fibre Channel family of standards (developed by the American National Standards Institute (ANSI)) defines a high speed communications interface for the transfer of large amounts of data between a variety of hardware systems such as personal computers, workstations, mainframes, supercomputers, storage devices and servers that have Fibre Channel interfaces. Use of Fibre Channel is proliferating in client/server applications which demand high bandwidth and low latency I/O such as mass storage, medical and scientific imaging, multimedia communication, transaction processing, distributed computing and distributed database processing applications.
A Fibre Channel network may consist one or more fabrics. A fabric is an entity that interconnects various ports attached to it and is capable of routing frames using only the D_ID information in an FC-2 frame header. A fabric may have zones to facilitate network management and operation. A zone is a group of zone members, where members of a zone are made aware of each other, but not made aware of other devices outside the zone. A zone can be defined to exist in one or more zone sets. Each zone has a zoning configuration, which includes a zone definition and a zone set state. The zone definition contains parameters that define a zone, including zone name, number of zone members and zone member definitions. The zone member definition contains parameters that define a zone member including the zone member type and zone member information. The zone set state is the state of a switch zone set (activated or deactivated).
When two fabrics are joined together, i.e. at least one switch in one fabric is connected to at least another switch in the other fabric, if zoning is present, then the two switches will attempt to merge their zoning information to ensure the zoning information is consistent across the joined fabric. The performance of the merge operation directly affects the processing time needed to allow the whole fabric to return to stable state as well as the overall performance of the switches during the merge operations.
The interface on a switch that connects to another device is a port. There are many different ports depending on the network topology and the type of devices that they are connecting. The port on a switch that connects to a port on another switch is an E_port. A port on a switch that connects to an end node is an F_port. The current invention is directed to the merge operation between switches, so only E_ports will be discussed.
FIG. 1 shows a small part of a Fibre Channel network 100, where a switch 102 is connected to another switch 104. SwitchA 102 has a zone configuration 112 cfgA and switchB 104 has a zone configuration 114 cfgB. Each switch 102, 104 has a checksum associated with the zone configuration. A zone configuration may have a size between several kilobytes to many megabytes depending on the switch or fabric configurations. In the examples discussed below, a zone configuration often runs to hundreds of kB. A checksum is typically much smaller, significantly less than 1 kB. A checksum acts as a shorthand or identifier for a particular configuration. In the same examples, a checksum is 32 bytes.
A merge computation performs a union of the two configurations in:cfgR=cfgA∪cfgB  (1)A simplified merge exchange is illustrated in FIG. 2 between switches 102 and 104. It is simplified in that it does not show all the transactions that may happen when two switches are connected. For example, FIG. 2 does not show many merge requests sent from switchB 104 to switchA 102; it does not show any possible Rejects because of busy conditions; and it does not show any possible retries as well.
A merge exchange includes several steps. Using FIG. 2 as a simplified example, the merge exchange may occur as follows. Assuming switchA 102 initiates the merge operation, switchA 102 sends a checksum request to switchB 104 (Req1) and switchB 104 sends a response back, which is its own checksum (Res1:ACC). SwitchA 102 compares the checksum received from switchB 104 with its own. If they are different, switchA 102 sends out an MR request with cfgA (Req2: MERGE). SwitchB 104 responds with cfgB in acknowledgement (Res2:ACC). SwitchB 104 computes ΔB cfgMerge(cfgB, cfgA) and installs the entries of ΔB. Then switchB 104 has a new configuration cfgR with a new checksum associated with the new configuration cfgR. When switchA 102 gets the response of cfgB, it also does a merge computation ΔA=cfgMerge(cfgA, cfgB) and installs the entries of ΔA. SwitchA 102 now has cfgR. After this, the merge initiated from switchA 102 finishes. SwitchB 104 also attempts or initiates a merge by sending checksum request (Req3: CHECK). SwitchA 102 responds back (Res3:ACC), which is switchA's 102 new checksum associated with the new cfgR. Since switchB 104 has the same cfgR after the merge operation which was initiated by switchA 102 and the same checksum, the checksums match. So the merge initiated from switchB 104 finishes.
As will be discussed below, in the above merge operation, there are many duplicate operations and unnecessary data transmissions in the network. It is desirable to perform the merge operation more efficiently.
When a switch 102 is connected to a network of several switches 104, 106, 108 and 109 as shown in FIG. 3 or FIG. 4, the merge operation may be more complicated and time consuming. In this case, switchA 102 and switchB 104 merge first in the same way as shown in FIG. 1 and discussed above. SwitchA 102 does cfgMerge (cfgA, cfgB), and switchB 104 does cfgMerge (cfgB, cfgA). Both switches have cfgR as a result. SwitchB 104 broadcasts this to switchC 106. Since the configuration on switchB 104 changes, there will be a merge operation between switchB 104 and switchC 106. SwitchB 104 does cfgMerge (cfgC, cfgB) and switchC 106 does cfgMerge (cfgB, cfgC). The same chain of events will propagate further down the path until every pair of connected switches have the same configuration. If one counts the merge exchanges, one can find three merge exchanges, and a total of six merge computations when switchA 102 is connected to the fabric comprising switchB 104, switchC 106 and device DeviceD 108, in the simple example shown in FIG. 4. There are more merge exchanges and merge computations for a more complicated configuration such as shown in FIG. 3, because of more connected pairs of switches. However, as will be discussed below, many of the operations are unnecessary. It is desirable to improve the merge operation.
Merge operations are typically performed on a connected port basis. If more than one pair of ports on two switches is connected, as shown in FIG. 5, each pair of ports will perform merge operations, even though the merges are the same for each pair. FIG. 5 shows an example where different numbers of pairs of ports are connected between switches within a fabric. In the example shown in FIG. 5, switchA 102 and switchB 104 have four (4) pairs of ports connected, i.e. links between ports 121 and 131, ports 123 and 133, ports 125 and 135 and ports 127 and 137. SwitchB 104 and switchC 106 have one pair of ports 136 and 144 linked. SwitchC 106 and deviceD 108 have two pairs of ports linked, ports 156 and 145, and ports 158 and 147. In FIG. 5, a few details of the network deviceD 108 and switchC 106 are shown. The network deviceD 108 has a network interface 156 containing ports 152 and 154 which are capable to connect to ports on other network devices, such as switchC 106. Within the deviceD 108, there is a control module 158 which is coupled to the network interface and controls the operation of the deviceD 108. The control module 158 is also coupled to a memory module 157 which stores operation data or device information, such as configuration data 159. DeviceD can be any entity within a network. Similarly, switchC may have several ports 141-148, a control module and a memory module. In the fabric shown in FIG. 5, some of the pairs may be trunked, i.e. they act as a single logical link, e.g. links 156-145 and 158-147 may be trunked as if they were a single link. When port 121 and port 131 are connected, both of them initiate merge operations as discussed above. When the other pairs of ports are connected between switchA 102 and switchB 104, when the links are not trunked, each of them will perform a merge operation again, even though the merge results are already known from the earlier merge between port 121 and port 131. Therefore, it is desirable to have a method or devices that can avoid the wasteful operations.
When two switches are connected, both switches will initiate a merge operation. They are likely to initiate at approximately the same time. The result is that both merge requests will be rejected with a reason of LOGICAL_BUSY. If not treated specially, both switches would wait for the other side to initiate a merge, thus missing the initial MERGE. The default waiting time is different for different switches. So after some waiting time, one switch will try again to initiate a merge request and not getting a rejection. It is desirable to avoid the waiting time.
As discussed above, the current merge operation may have redundant merge computations, redundant merge exchanges, unnecessary merge retries across the fabric and extra waiting time. These inefficiencies make the merge operation prolonged and the fabric wait a longer time to be stable. It is desirable to have a method, a device and a system that make merge operations more efficient.